Thin clients are defined as clients that perform little or no local data processing. Instead of relying on local processing power, thin clients couple through a network to a corresponding central computer that executes applications on behalf of the thin clients. In such applications, the central computer (such as a server) typically generates output streams including audio and video data over a network to the thin client such as a desktop device. The thin clients typically play back the audio data or display the video data as such data is received from the central computer.
Depending on the application, the transmission speed of a network connection between a thin client and the central computer can vary widely such as around 300 kilobits per second on a DSL line to around 100 Mega bits per second in a local area network application. Higher speed network connections enable a thin client to perform higher performance operations assuming that the network connection is a bottleneck rather than the processing capability at the central computer. Because the thin client depends so heavily on throughput of a communication link with the central computer, such links need to be used as efficiently as possible.
Characteristics of data sent to a thin client (e.g., desktop unit) are somewhat different than most network traffic (e.g., files or web pages) which is transmitted in accordance with an acknowledgment based protocol such as TCP/IP (Transmission Control Protocol/Internet Protocol). One potentially significant property associated with file transfers and web page accesses is that all of the data typically must be reliably delivered reliably and correctly ordered to the application attempting to access the data. Even loss of a single byte of data may be unacceptable. The standard Transmission Control Protocol, on top of the Internet Protocol (such as TCP/IP), supports data transmissions with the desirable property that lost data packets are retransmitted until all data is properly received at a receiver. For example, if data is lost during transmission, the TCP protocol causes retransmission of lost data until the sender acknowledges receipt of the data. Delays and throttling mechanisms are sometimes implemented in TCP sending and retransmission algorithms to make efficient use of the available bandwidth and to avoid causing over-congestion in the network.
In a thin client application, time is of the essence. Audio data in a thin client application must be received at the thin client at the right time to drive a corresponding output device such as a speaker. Otherwise, the audio output from the speaker will be of poor quality. Smooth audio output is usually accomplished via use of buffering at the thin client to allow for some time variance of receiving audio packets. Unlike TCP, loss of an audio packet in the network does not cause the sender to retransmit that particular data. This is largely because real-time data received too late in time tends to be useless for playback purposes. Instead, the audio playback at the thin client just continues, perhaps with some audible defect or display as a result of one or more occasional lost packets. An appropriate network protocol for this type of traffic is the User Datagram Protocol (UDP) over the Internet Protocol (IP). UDP provides unreliable transmission of packets, leaving it up to a higher level protocol to recover from lost or mis-ordered packets.